Your Complete Checklist for Achieving HIPAA Compliance

HIPAA Compliance Requirements: The Complete Guide, Updated for 2025 Security Rule Changes

The Health Insurance Portability and Accountability Act establishes federal standards for protecting patient health information across the organizations that create, receive, maintain, or transmit it. HIPAA compliance is not a single checklist — it is a framework of four interlocking rules that govern privacy, security, breach notification, and data processing across both the covered entities that directly handle patient care and the business associates that support them.

Understanding what HIPAA actually requires — not just that it exists — is the starting point for building a compliance program that holds up under OCR scrutiny. This guide covers all four rules, the 2025 proposed Security Rule updates that represent the most significant overhaul in over a decade, the penalty structure for noncompliance, and what organizations need to implement to satisfy each requirement in practice.

Executive Summary

Main Idea: HIPAA compliance requires satisfying four rules — Privacy, Security, Breach Notification, and Omnibus — across administrative, physical, and technical domains. For both covered entities and business associates, compliance means not just implementing controls but maintaining documented evidence that those controls are operational. The 2025 proposed Security Rule amendments, if finalized, will make encryption, multi-factor authentication, and network segmentation mandatory for all covered entities and business associates — eliminating the “addressable” flexibility that organizations have historically relied on.

Why You Should Care: The Office for Civil Rights resolved 63 enforcement actions in 2024 alone, with penalties ranging from tens of thousands to tens of millions of dollars. Healthcare was the most breached industry for the fourteenth consecutive year. OCR’s enforcement posture has shifted from reactive — responding to breach reports — to proactive, with an active audit program targeting covered entities and business associates regardless of whether a breach has occurred. The standard for HIPAA compliance is not having a program on paper. It is being able to demonstrate that the program is working when OCR asks.

Key Takeaways

1. HIPAA applies to covered entities and business associates equally.

Since the 2013 Omnibus Rule, business associates — the vendors, cloud providers, billing companies, and technology partners that handle PHI on behalf of covered entities — face the same HIPAA compliance requirements and penalty exposure as the healthcare organizations they serve. A Business Associate Agreement is required by law, but it is not a substitute for technical controls. A BAA that assigns compliance obligations without the underlying encryption, access controls, and audit logging to back them up is a contractual document with an unenforceable security posture.

2. The 2025 Security Rule proposed amendments remove the “addressable” safety valve.

Under the original HIPAA Security Rule, safeguards were classified as either “required” or “addressable.” Required safeguards had to be implemented. Addressable safeguards had to be implemented unless a covered entity could document a reasonable alternative. In practice, many organizations used the addressable designation to defer encryption and other controls. The 2025 proposed amendments eliminate this distinction entirely — making encryption at rest and in transit, multi-factor authentication, network segmentation, and several other safeguards mandatory for all covered entities and business associates, with no documented-alternative pathway.

3. Risk assessment is required, not optional — and it must be current.

The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. OCR has been explicit in enforcement actions that a risk analysis conducted years ago without subsequent updates does not satisfy this requirement. A HIPAA risk assessment is not a one-time exercise — it must be reviewed and updated periodically, and whenever significant operational or environmental changes occur.

4. Business associate relationships extend your compliance perimeter — and your liability.

Every vendor, cloud service provider, or technology partner that accesses, stores, or transmits PHI on your behalf is a business associate. Their security failures are your compliance exposure. Under HIPAA, covered entities must implement technical and contractual safeguards that govern how business associates handle PHI — and those safeguards must be operationally enforced, not just documented in a BAA. The 2025 proposed amendments strengthen business associate oversight requirements, including annual audits and tighter incident notification timelines.

5. Audit logs are mandatory infrastructure, not optional reporting features.

The HIPAA Security Rule’s Audit Controls standard (45 C.F.R. § 164.312(b)) requires covered entities and business associates to implement mechanisms that record and examine activity in systems containing ePHI. These are not soft requirements — OCR enforcement actions regularly cite incomplete or absent audit logging as a Security Rule violation. An audit trail that captures who accessed PHI, when, from what system, under what authorization, and with what outcome is both the detection mechanism for security incidents and the evidentiary record that demonstrates compliance when an audit arrives.

Who HIPAA Applies To

HIPAA applies to two categories of organization: covered entities and business associates.

Covered entities are healthcare providers that transmit health information electronically (hospitals, physician practices, clinics, pharmacies), health plans (insurers, HMOs, employer-sponsored health plans), and healthcare clearinghouses that process health information from one format to another.

Business associates are organizations that perform functions or activities on behalf of a covered entity that involve the use or disclosure of PHI. This includes cloud service providers that store ePHI, managed service providers that administer healthcare IT systems, billing companies, transcription services, legal counsel, accountants, and any technology platform through which PHI flows. Since the 2013 Omnibus Rule, business associates face the same penalty exposure as covered entities for violations — the BA designation does not create a compliance buffer.

Organizations that do not create, receive, maintain, or transmit PHI are generally not subject to HIPAA. But the threshold for business associate status is lower than most organizations assume. A cloud storage provider that hosts encrypted PHI — even without the ability to access it — is a business associate under HIPAA and must execute a BAA and implement appropriate safeguards.

The Four HIPAA Rules

The Privacy Rule

The HIPAA Privacy Rule establishes national standards for the protection of individually identifiable health information — defining what constitutes Protected Health Information (PHI), who can use or disclose it, under what circumstances, and with what patient rights attached.

PHI is any information that relates to an individual’s past, present, or future health condition, the provision of healthcare, or payment for healthcare — and that can identify the individual. The 18 HIPAA identifiers range from names and dates to geographic data and device identifiers. De-identified data — from which all 18 identifiers have been removed using an approved method — falls outside HIPAA’s scope.

The Privacy Rule permits PHI use and disclosure for treatment, payment, and healthcare operations without patient authorization. It requires authorization for most other disclosures. Patients have the right to access their own PHI, request amendments, receive an accounting of disclosures, and request restrictions on use. The Minimum Necessary standard requires covered entities and business associates to limit PHI access to the minimum necessary for each specific purpose — a requirement that applies equally to human access and AI system access.

For a detailed breakdown of Minimum Necessary requirements and role-based access implementation, see HIPAA Minimum Necessary Rule: Complete Compliance Guide.

The Security Rule

The HIPAA Security Rule establishes national standards for protecting electronic PHI (ePHI) — PHI that is created, received, maintained, or transmitted in electronic form. It requires covered entities and business associates to implement administrative, physical, and technical safeguards that ensure the confidentiality, integrity, and availability of ePHI.

Administrative safeguards are the policies, procedures, and training programs that govern how an organization manages ePHI security. They include the security management process (risk analysis and risk management), workforce training, access management, contingency planning, and business associate oversight. The Security Rule requires a designated Security Officer responsible for developing and implementing security policies and procedures.

Physical safeguards govern access to the physical systems and facilities where ePHI resides. They include facility access controls, workstation use policies, workstation security, and device and media controls covering how electronic media containing ePHI is handled, moved, and disposed of.

Technical safeguards are the technology-based controls that protect ePHI and control access to it. They include access controls (unique user identification, automatic logoff, encryption and decryption), audit controls, integrity controls (ensuring ePHI is not improperly altered or destroyed), and transmission security (protecting ePHI transmitted over electronic communications networks).

For full technical safeguard detail, see HIPAA Security Rule Requirements and 2025 Updates.

The Breach Notification Rule

The HIPAA Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in some cases the media, following a breach of unsecured PHI. Business associates must notify the covered entity without unreasonable delay and no later than 60 days following discovery of a breach.

The notification timeline for covered entities is strict: affected individuals must be notified without unreasonable delay and no later than 60 days from discovery. Breaches affecting 500 or more individuals in a single state or jurisdiction also require notification to prominent media outlets. All breaches must be reported to HHS — breaches affecting 500 or more individuals must be reported within 60 days of discovery; smaller breaches may be reported annually.

PHI that was encrypted at the time of a breach — and whose encryption keys remained secure — qualifies for the Breach Notification Rule’s safe harbor. Encrypted data is considered “unusable, unreadable, or indecipherable” and does not trigger notification requirements. This safe harbor is one of the most operationally significant reasons to implement encryption: a breach of properly encrypted PHI is not a reportable HIPAA breach. For the full encryption safe harbor analysis, see AES-256 Encryption for HIPAA: Breach Safe Harbor Guide.

The Omnibus Rule

The 2013 Omnibus Rule made several structural changes to HIPAA that remain in effect. Most significantly, it extended full HIPAA compliance obligations and penalty exposure to business associates and their subcontractors — closing the liability gap that had previously allowed downstream vendors to operate under less stringent requirements. It also strengthened patient rights (including the right to request copies of ePHI held in electronic health records), limited the use of PHI for marketing purposes, and prohibited the sale of PHI without patient authorization.

The 2025 Security Rule Proposed Amendments

In January 2025, HHS proposed the most significant overhaul of the HIPAA Security Rule since its original publication. The proposed amendments respond to the surge in healthcare breaches and ransomware attacks that have exposed the gaps created by inconsistent implementation of the original rule’s “addressable” safeguard designation.

The core change: the proposed amendments eliminate the distinction between “required” and “addressable” implementation specifications. Under the amended rule, the following safeguards would become mandatory for all covered entities and business associates, with no documented-alternative pathway:

Encryption of ePHI at rest and in transit. Both encryption at rest (covering stored ePHI in databases, file systems, and backup media) and encryption in transit (covering ePHI transmitted over any electronic network) would be mandatory. The proposed amendments reference FIPS-validated encryption standards — effectively making FIPS 140-3 validated cryptographic modules the required implementation standard.

Multi-factor authentication. MFA would be required for all access to systems containing ePHI. Single-factor password-based authentication would no longer satisfy Security Rule requirements.

Network segmentation. Covered entities and business associates would be required to implement network controls that isolate systems containing ePHI from other network segments — limiting lateral movement in the event of a breach.

Annual technology asset inventories. Organizations would be required to maintain current inventories of all technology assets that access, store, or transmit ePHI — a foundational requirement for accurate risk assessment and incident response.

Documented risk analysis with specific scope requirements. The proposed amendments make the risk analysis requirement more specific, defining what the analysis must include and requiring organizations to document identified risks, their likelihood and impact, and the controls implemented to address them.

Written incident response and disaster recovery plans with 72-hour restoration capability. Organizations would be required to maintain documented plans for responding to security incidents and restoring systems within 72 hours of a disruption.

Annual compliance audits and enhanced vendor oversight. The proposed amendments strengthen business associate oversight requirements, including contractual provisions for annual compliance verification.

As of July 2026, these amendments remain in proposed form — the formal rulemaking process is ongoing. Organizations should not wait for final publication to begin implementation. The proposed changes reflect OCR’s enforcement posture regardless of their formal status, and the 2025 HISAA legislation introduced by Senators Wyden and Warner would impose even more stringent requirements if enacted. For the current status of these proposals, see HIPAA Security Rule Requirements and 2025 Updates.

HIPAA Penalties and Enforcement

HIPAA violations carry civil and criminal penalties that scale with the severity and willfulness of the noncompliance.

Civil penalties are tiered by knowledge and culpability. Organizations unaware of a violation face a minimum of $100 per incident. Violations with reasonable cause but without willful neglect carry a minimum of $1,000 per incident. Willful neglect that is corrected carries a minimum of $10,000 per incident. Willful neglect that is not corrected carries a minimum of $50,000 per incident. Annual caps per violation category are $25,000 for the lowest tier and $1.5 million for the highest — though OCR has interpreted this cap per calendar year per violation type, meaning multi-year noncompliance multiplies exposure significantly.

Criminal penalties apply to knowing violations and are prosecuted through the Department of Justice. Knowingly obtaining or disclosing PHI in violation of HIPAA carries fines up to $50,000 and up to one year in prison. Violations committed under false pretenses increase the ceiling to $100,000 and five years. Violations with intent to sell, transfer, or use PHI for commercial advantage or personal gain carry fines up to $250,000 and up to ten years in prison.

OCR’s enforcement actions have increasingly targeted organizations across the full spectrum of healthcare — not only large health systems but physician practices, health plans, and business associates. Corrective Action Plans accompanying settlements typically impose multi-year monitoring obligations and mandatory compliance program improvements that extend well beyond the initial penalty.

Building a HIPAA-Compliant Technical Architecture

The Security Rule’s technical safeguard requirements translate to a specific set of platform capabilities that covered entities and business associates must implement. The gap between having individual tools that satisfy individual requirements and having a unified architecture that satisfies all of them simultaneously is where most organizations accumulate compliance risk.

Encryption across all channels. ePHI moves through more channels than most organizations account for: email, file sharing, managed file transfer, web forms, API integrations, and increasingly AI systems accessing clinical data. Each channel must implement AES-256 encryption at rest and TLS 1.2 minimum (TLS 1.3 preferred) in transit. Channels that encrypt some PHI flows but not others create safe harbor gaps — a breach of unencrypted PHI through an unencrypted channel triggers breach notification regardless of how well-protected other channels are. For an audit trail checklist, see HIPAA Audit Logs: Complete Requirements.

Access controls enforcing Minimum Necessary. Technical access controls must limit ePHI access to the minimum necessary for each specific purpose. Role-based access control (RBAC) establishes which personnel can access which PHI categories. Attribute-based access control (ABAC) applies dynamic, context-aware policies that enforce Minimum Necessary at the operation level — not just at the account level. Unique user identification, automatic session termination, and emergency access procedures are additional technical safeguard requirements.

Immutable audit logging across all ePHI-touching systems. Audit logs must capture every access event — who accessed what PHI, when, from what system, under what authorization, and what action they took. Logs must be stored in a format that cannot be altered after the fact. Organizations with fragmented logging across email systems, file sharing platforms, EHR audit modules, and network infrastructure cannot produce a coherent audit trail for OCR review — which is why consolidated, cross-channel logging is a practical compliance requirement, not just a best practice.

Business associate technical governance. A BAA is required by law. Technical controls governing what PHI business associates can access, logging their access in the same audit trail as internal users, and revoking access when relationships end are required by the Security Rule. The compliance obligation follows the data — PHI in a business associate’s environment is still the covered entity’s compliance responsibility.

For the complete five-step implementation framework, see 5 Steps to Achieve HIPAA Compliance.

How Kiteworks Supports HIPAA Compliance

Kiteworks is built for the data governance requirements that HIPAA imposes on covered entities and business associates handling ePHI across multiple exchange channels.

On encryption: Kiteworks applies AES-256 encryption at both the file level and the disk level — double encryption — with FIPS 140-3 validated cryptographic modules. Customer-owned encryption keys mean Kiteworks is technically incapable of decrypting customer data. ePHI transmitted through any Kiteworks channel — secure email, secure file sharing, managed file transfer, SFTP, or secure data forms — is protected by TLS 1.2 minimum, with TLS 1.3 available. Properly encrypted PHI on the Kiteworks platform qualifies for HIPAA’s breach notification safe harbor.

On access controls: Kiteworks enforces both RBAC and ABAC policies through a unified Data Policy Engine. Access is governed per file, per folder, and per user — with Minimum Necessary enforcement at the operation level. External recipients (business associates, referral partners, patients accessing their own records) are authenticated before access is granted. Access can be revoked after the fact. SafeVIEW view-only access allows PHI to be shared for review without leaving the Kiteworks environment.

On audit logging: every access event across every Kiteworks channel is logged in a single, consolidated, immutable audit trail. The log captures who accessed what, when, from what system, under what authorization, and what action they took — across email, file sharing, MFT, SFTP, secure forms, and AI data access. The audit trail is SIEM-integrated and available in HIPAA-specific compliance reporting views. This is the audit infrastructure that satisfies the Security Rule’s Audit Controls standard and supports OCR-defensible breach investigation.

On business associate compliance: Kiteworks signs Business Associate Agreements as a business associate and holds FedRAMP Moderate Authorization — an independently assessed, continuously monitored security posture that provides covered entities with a documentable basis for business associate due diligence beyond the contractual BAA.

For AI-specific HIPAA requirements, including how the 2025 Security Rule amendments apply to AI agents accessing ePHI, see AI Agents and HIPAA: Solving the PHI Access Challenge.

To see how Kiteworks applies to your specific HIPAA compliance environment, schedule a custom demo.

Frequently Asked Questions

HIPAA compliance requires satisfying four rules. The Privacy Rule governs who can use and disclose PHI, patient rights, and the Minimum Necessary standard for limiting PHI access. The Security Rule requires administrative, physical, and technical safeguards for electronic PHI — including risk assessment, access controls, encryption, and audit logging. The Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in some cases the media within 60 days of discovering a breach of unsecured PHI. The Omnibus Rule extended full compliance obligations and penalty exposure to business associates and their subcontractors. Both covered entities and business associates must satisfy all four rules.

The 2025 proposed amendments represent the most significant overhaul of the HIPAA Security Rule since its original publication. The central change is eliminating the distinction between “required” and “addressable” implementation specifications — making encryption of ePHI at rest and in transit, multi-factor authentication, and network segmentation mandatory for all covered entities and business associates, with no documented-alternative pathway. The proposed amendments also add requirements for annual technology asset inventories, more specific risk analysis documentation, written incident response and disaster recovery plans with 72-hour system restoration capability, and enhanced business associate oversight. As of July 2026, the amendments remain in proposed form, but organizations should treat the proposed requirements as the current compliance standard given OCR’s enforcement posture.

A Business Associate Agreement (BAA) is a contract required by HIPAA between a covered entity and any vendor or third party — a business associate — that creates, receives, maintains, or transmits PHI on the covered entity’s behalf. The BAA must specify the permitted uses of PHI, require the business associate to implement appropriate safeguards, mandate breach notification, and grant the covered entity audit rights. Since the 2013 Omnibus Rule, business associates face the same penalty exposure as covered entities for violations occurring in their environments — the BAA does not transfer liability, it documents shared obligations. A BAA without underlying technical controls is a contractual document without an operative security posture.

Under the original HIPAA Security Rule, encryption was classified as an “addressable” implementation specification — meaning covered entities had to implement it unless they could document a reasonable and appropriate alternative. In practice, the documentation burden for not encrypting ePHI, combined with the loss of breach notification safe harbor protection for unencrypted PHI, made non-encryption a compliance risk rather than a legitimate alternative. The 2025 proposed amendments remove this ambiguity entirely, making encryption of ePHI at rest and in transit mandatory. OCR enforcement actions have consistently cited encryption failures as Security Rule violations regardless of the “addressable” designation. FIPS 140-3 validated encryption is the current federal standard.

The HIPAA Breach Notification Rule’s safe harbor applies when PHI that was breached was encrypted at the time of the breach and the encryption keys were not also compromised. Encrypted data is considered “unusable, unreadable, or indecipherable” under HHS guidance — and a breach of properly encrypted PHI does not trigger HIPAA’s notification requirements for individuals, media, or HHS. This safe harbor is one of the most operationally significant reasons to implement FIPS-validated encryption across all channels handling ePHI. Customer-owned encryption keys strengthen safe harbor claims by ensuring that even a cloud vendor breach does not compromise decryptable PHI — because the vendor never possessed the keys needed to decrypt it.

Get started.

It’s easy to start ensuring regulatory compliance and effectively managing risk with Kiteworks. Join the thousands of organizations who are confident in how they exchange private data between people, machines, and systems. Get started today.

Table of Content
Share
Tweet
Share
Explore Kiteworks